I agree this should go in the file, but I am hesitant to say that should be the native file. This is not a property of arbitrary machines (build, host, and target); it is as best a property that tends to vary with the host machine.

Yeah #4637 is a fine idea, but I'd want it to be independent of #3972. If anything, the "flags" file would store what machine files were passed in, like any other command line argument.

As I mentioned, I'd like to allow these paths to be specified in both the native file (the build machine config files, if you will) as well as the cross file (the host and target machine config files). for cross files though I need to tinker with some assumptions the backend has, namely that there will only be one prefix.

And I do think it really is a property of the build machine. Take for example libdir (assume x86 and linux),
on Archlinux 64 bit libraries go in /lib, and 32 bit libraries go in /lib32
on Fedora 64 bit libraries go in /lib64 and 32 bit libraries go in /lib32
on debian 64 bit libraries go in /lib/x86_64-linux-gnu and 32 bit go in /lib/i386-linux-gnu

Even if you're doing a "native" build for a different distro you might need a different libdir. I think that the cross file version is probably more interesting from an end user point of view, but not having 3 different files that a user needs to copy to replicate a build is also a feature.

How is there multiple prefixes with a cross build? There's DESTDIR-like functionality---I'm "installing" it on this machine but I'll actually have to copy the files elsewhere before I use it---but that's different.

In general, the build machine is purely an implementation detail, all interface details should stem from the host machine and target machine. [A prefix in the target machine would be where the newly-build compiler would install things by default, but that doesn't really make much sense.]

In short, the host machine is the one on which software runs, the install directory is where the problem runs. Because of the common thread of "program runs", I deem the install dir a host machine property.

Take this super trivial case:

executable('foo', 'foo.cpp', native : true, install : true)
executable('cross_foo', 'foo.cpp', native : false, install : true)

Currently foo and cross_foo would be installed into the same prefix, even though one is compiled for the build machine and the other for the host machine. This is broken IMHO, which leaves us with two choices:

1. allow two prefix, one of the build and one for the host
2. error if trying to install native : true binaries in a cross build

Thinking about it more 2 is probably a better solution, which actually means I can just add my patches to add this to the cross file as well.

If we want to limit ourselves 2-3 files ("native and cross" or "file per machine") and not more, I'd permit the [path] section in both native and cross files, but simply have the cross file override the native one. This matches how the host_machine defaults to the build_machine if not explicit definition is given.

@dcbaker yes 2 is better. I have implemented that in fact in my mammoth PR #4010. Let me find it. I don't see it; I think I was getting confused with the mixed-platforms dependency warning.

Yeah, here's how I'm leaning:
"native build": cmd line > native file
"cross build": cmd line > cross file

such that in a cross build the paths section from the native file is completely ignored

Yeah I'm not sure that should be true for all CLI flags, but that the right way for this.

The unix tradition is that command line > config, and I've been going with that. I think that will surprise people less.

Oh yes I agree with the direction of the >. I just meant that some options should still come from the native build file in cross builds; it depends on the flag in question.

Right, what I'm suggesting is in a case like:

[paths]
prefix = '/usr/x86root'
libdir = 'lib32'

and the command line meson builddir --libdir=lib --cross-file=mycross,

that prefix would be /usr/x86root, and the libdir would be lib, command line arguments in unix tradition override config file variables.

ping

Instead of "paths" should this be "options" so you could provide a value for any option, not just paths?

Well, I'm not sure what the right thing to do is here. In cross files we store some options as properties, like c_args. But you're probably right, it probably makes sense to store these in an [options] section.

#4626 makes [properties] and compiler_options play a lot nicer. I'm kind of wary about how free-form options are and wouldn't want that to leak further into config files too.

[paths] and [compiler_options] makes sense to me, with [properties] deprecated. [options] is rather vague; everything in a config file is an option!

@jpakkane, preferences here, I'd like to get this merged and I'm happy to change the name to whatever you like.

Let's go with the current [paths]. Even if we had a way to add general command line options, having different types in their own segments includes readability.

@Ericson2314 For the moment I've just used the PerMachineDefaultable as-is. I'm not entirely happy with it, but that is life.

@dcbaker Sounds good. I'll try some of those factor refactors, say once I'm done with #4010.

Oh a last thing for this PR, which otherwise looks great. Instead of trying to detect the default and override conditionally, can we always set the options based on the user config before we slurp in CLI flags? See https://github.com/mesonbuild/meson/pull/4626/files#diff-246a2f6d498375c5981f0ca48d99cae2R585 for where I did this with the compiler options

@Ericson2314, that was no small ask :) I do think that the result is nicer (no more tracking of default arguments), but it was basically a complete rewrite of the series. Hopefully this version is ready.

@dcbaker All the more thanks then! I when through it one last time, commit by commit, and it looks good.

@jpakkane how do you feel about this?